home *** CD-ROM | disk | FTP | other *** search
-
- WNILS Working Group Joan Gargano
- Internet Draft Ken Weiss
- July 1, 1993 University of California, Davis
-
-
- Whois and Network Information Lookup Service
- Whois++
-
-
- Status Of This Memo
-
- This Internet Draft proposes changes to the NICNAME/WHOIS protocol
- described in RFC 954. Distribution of this memo is unlimited.
-
- This document is an Internet Draft. Internet Drafts are working
- documents of the Internet Engineering Task Force (IETF), its Areas,
- and its Working Groups. Note that other groups may also distribute
- working documents as Internet Drafts.
-
- Internet Drafts are draft documents valid for a maximum of six
- months. Internet Drafts may be updated, replaced, or obsoleted by
- other documents at any time. It is not appropriate to use Internet
- Drafts as reference material or to cite them other than as a "working
- draft" or "work in progress." Please check the 1id-abstracts.txt
- listing contained in the internet-drafts Shadow Directories on
- nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or
- munnari.oz.au to learn the current status of any Internet Draft.
-
- This Internet Draft expires December 31, 1993.
-
- I. Introduction
-
- As currently defined, NICNAME/WHOIS service is a TCP transaction based
- query/response server, running on a few specific central machines, that
- provides netwide directory service to Internet users. The Network
- Information Center (NIC) maintains the central NICNAME database and
- server, defined in RFC 954, providing online look-up of individuals,
- network organizations, key host machines, and other information of
- interest to users of the Internet. The usefulness of this service has
- lead to the development of other distributed directory information
- servers and information retrieval tools and it is anticipated more will
- be created. Many sites now maintain local directory servers with
- information about individuals, departments and services at that specific
- site.
-
- Typically these directory servers are network accessible. Local
- development of these services has resulted in wide variations in the
- type of data stored, access methods, search schemes, and user interfaces.
- The purpose of the Whois and Network Information Lookup Service Working
- Group (WNILS) is to expand and define the standard for WHOIS types of
- services, to resolve issues associated with the variations in access and
- provide a consistent and predictable service across the network. This
- Internet Draft describes new features for WHOIS to meet these goals.
-
-
- 1
-
-
- WNILS Working Group Whois++ Lookup Service Gargano, Weiss
-
-
- II. Architecture
-
- The WHOIS service should be provided in a client/server model. There are
- no restrictions on the design of the client, provided it is capable of
- passing queries to the server in the proper format, and capturing the
- server's response in some useful format. Existing WHOIS specifications
- call for clients to display responses in human-readable form. This more
- general proposal does not impose that restriction.
-
- This paper acknowledges the existence of many distributed information
- servers, and anticipates the creation of many more. To help users locate
- WHOIS servers, each server should have a nameserver entry in the form
- "whois.domain", i.e. whois.internic.net.
-
-
- III. Client Design and Behavior
-
- The client provides the user interface to the WHOIS system and a
- mechanism for query generation and display of the response. The client
- is responsible for providing support for paging of long output from the
- server. All clients must provide this service. The server will not
- include any special characters, or make any efforts to control output to
- a screen.
-
- Special search criteria may be specified by the use of keywords or
- special characters, some of which are defined in RFC 954. Clients
- should be designed to make support for quoted strings unnecessary.
-
-
- IV. Server Design and Behavior
-
- The server should return the same information in response to a given
- query consistently, regardless of the client software or the hardware
- used to originate the query. Queries should be evaluated on a
- case-insensitive basis. Spaces should not be considered in searches.
- A search for "La Russo" should return both "LaRusso" and "La Russo" as
- matches.
-
- There are three types of data records supported in this proposal:
- records for people, hosts, and domains.
-
- Individual records
-
- Name Name of the individual required
-
- Organization Name of the organization required
-
- Organization-type Type of organization optional
- (university, commercial,
- research)
-
- Work-telephone Work telephone number optional
-
-
- 2
-
- WNILS Working Group Whois++ Lookup Service Gargano, Weiss
-
-
-
- Fax-telephone Fax telephone number optional
-
- Work-address Work postal address optional
-
- Title Working title or position optional
- within an organization
-
- Department Department optional
-
- Email-address Email address in RFC 822 optional
- format for this individual
-
- Handle A unique identifier for this required
- record on the local server
-
- Last-update Date this record was last required
- updated
-
- Home-telephone Home telephone number optional
-
- Home-address Home postal address optional
-
-
- Host records
- Domain records
-
- Domain-name Domain name registered with the required
- Network Information Center (NIC)
-
- Network-address Network address associated with this required
- domain name
-
- Admin-name Name of the Administrative Contact for required
- this domain
-
- Admin-address Postal address of the Administrative required
- Contact for this domain
-
- Admin-telephone Telephone number of the Administrative required
- Contact for this domain
-
- Admin-email Electronic mail address in RFC 822 required
- format for the Administrative Contact
- for this domain
-
- Tech-name Name of the Technical Contact for this required
- domain
-
- Tech-address Postal address of the Administrative required
- Contact for this domain
-
-
- 3
-
- WNILS Working Group Whois++ Lookup Service Gargano, Weiss
-
-
- Tech-telephone Telephone number of the Technical required
- Contact for this domain
-
- Tech-email Electronic mail address in RFC 822 required
- format for the Administrative Contact
- for this domain
-
- Nameservers Primary domain nameservers for this optional
- domain
-
- Last-update Last date this record was updated required
-
-
- Search Options
-
- A unique handle must be provided for every record in the serve
- database to target specific records for display. For example, if
- there are three individuals named, respectively, A. La Russo,
- B. LaRusso, and C. Larusso, then a search for "LA RUSSO" would return
- all three as matches. However, each record would have a unique handle,
- i.e. LARUSSO1, LARUSSO2, and LARUSSO3. A search for any one of these
- handles would return a single match for that particular individual.
- This is consistent with the RFC 954 query, "whois !SMITH1"
-
- Other search options which should be supported are:
-
- whois smith exact match on last name
-
- whois smith,j exact match on last name, first name
- whois "smith,j" begins with "J"
- whois j. Smith
- whois "j. Smith"
-
- whois smith, john exact match on last and first names
- whois "smith, john"
- whois john Smith
- whois "john Smith"
- whois .john Smith
-
- whois "smith..." all last names beginning
- whois smith* with Smith
- whois begins smith
-
- whois smith?? all last names beginning with
- "Smith" and containing up to two
- letters after "Smith", i.e. "Smith",
- "Smithy", "Smithey" and "Smithie"
-
- whois ends smith all last names ending in "smith"
-
- whois exact A Martinez exact match for "A Martinez"
-
-
- 4
-
- WNILS Working Group Whois++ Lookup Service Gargano, Weiss
-
-
- whois fuzzy paulson all last names that sound like or
- are spelled like "Paulson"
-
- whois first Kazuko exact match on first name "Kazuko"
-
- whois first begins Art all first names beginning with "Art"
-
- whois first fuzzy Kasuko all first names that sound like or
- are spelled like "Kasuko"
-
- whois hamlet.ucdavis.edu IP address and other information
- whois system hamlet.ucdavis.edu on the computer called
- hamlet.ucdavis.edu.Could be served
- by a domain name service querytype
- (QTYPE) *
-
- whois system hamlet IP address and other
- information on the computer called
- hamlet with the default domain
- appended. Could be served by a
- domain name service querytype
- (QTYPE) *
-
- whois 128.120.2.9 domain name and other
- whois system 128.120.2.9 information on the computer at
- specified IP address. Could be served
- by a domain name service querytype
- (QTYPE) PTR.
-
- whois !ucdavis-dom site contacts and other
- whois domain ucdavis.edu information on the site ucdavis
-
- If any keywords are specified in the query, the server will complete
- that specific query and return the results (even if 0 matches are
- found). If no keywords are specified, the server will interpret the
- query based upon the rules above. Optionally, the server may be
- configured so that if a search yields no matches, the query will
- automatically be run again, but with the keyword begin inserted.
-
- Servers must support multiple levels of detail in response to queries.
- A query yielding multiple matches should return a short-form record
- for each match. A query yielding a single match should return a
- long-form record. A query yielding no matches should return
- context-sensitive help on expanding the search criteria.
-
-
- On-line Help
-
- The client should return a minimal (two line) help message for every
- query sent to the server. That message should identify the database
- being searched and provide instructions for the user to obtain more
- detailed help screens.
-
- 5
-
- WNILS Working Group Whois++ Lookup Service Gargano, Weiss
-
-
- Additional help should be provided in special situations. The server
- should recognize queries that return zero matches, and provide a brief
- help message explaining how to broaden a search. If a search returns
- more than 50 matches, the server should take two actions. First, the
- user should get a message explaining how to narrow searches. Second,
- the user should be offered the option of re-specifying the search, or
- receiving all matching responses. When multiple matches are found and
- returned to the client, the server should add a brief help message
- explaining how to use handles to narrow the search to a single record.
-
- If the client queries for "help" or "?" then the server should return
- a complete help file. The help file should contain information in
- sufficient detail for the user to understand and access all the features
- of WHOIS service.
-
-
- V. Extensibility
-
- This Internet Draft defines a limited set of data records and fields
- for reliable whois queries. Mechanisms exist, Deutsch, et. al. August
- 1992, for whois clients to discover extended data records and query for
- fields not defined in this draft. It is recommended that Whois clients
- and servers include this functionality to maximize the extensibility and
- usefulness of this service.
-
-
- VI. References
-
- Deutsch, et al. Architecture of the WHOIS++ service. August 1992.
- Available by anonymous FTP as
- ftp.ucdavis.edu://pub/archive/wnils/Architecture.Overview
-
- VII. Authors Addresses
-
- Joan Gargano
- Information Technology
- Distributed Computing Analysis and Support
- University of California
- Davis, CA 95616
- jcgargano@ucdavis.edu
-
- Ken Weiss
- Information Technology
- Distributed Computing Analysis and Support
- University of California
- Davis, CA 95616
- krweiss@ucdavis.edu
-
-
- This Internet Draft expires December 31, 1993.
-
-
- 6
-